home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
infosrvr
/
dev
/
www_talk.930
/
000238_davis@dri.cornell.edu _Fri Oct 16 17:11:18 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1994-01-24
|
2KB
Return-Path: <davis@dri.cornell.edu>
Received: from dxmint.cern.ch by nxoc01.cern.ch (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA13607; Fri, 16 Oct 92 17:11:18 GMT+0100
Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
id AA09624; Fri, 16 Oct 92 17:12:09 +0100
Received: by willow.tc.cornell.edu id AA06348
(5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Fri, 16 Oct 1992 12:11:46 -0400
Date: Fri, 16 Oct 1992 12:11:46 -0400
From: Jim Davis <davis@dri.cornell.edu>
Message-Id: <199210161611.AA06348@willow.tc.cornell.edu>
To: www-talk@nxoc01.cern.ch
Subject: non-text documents
Can you tell us when WWW and Viola will support non-text
documents? I would very much like to be able to return
pictures including Postscript. I know this has been discussed
in the past.
One issue is how will the client know what kind of data
is being returned. It seems there are several possibilities:
1) Make the client figure it out itself by examining the data (e.g.
for "magic numbers"). Simplest, but makes the client do too much
work.
2) Use typed links. A server which wishes to return non-text data
first returns a constructed document containing anchors where the link
type somehow encodes the data type. Benefit here is that it allows
the user to choose the kind of data if there is a choice.
3) the HTTP protocol to allow an HTTP server to inform the client of
the kind of data to be returned, maybe even negotiate about it.
4) Extend HTML to allow embedded non-text data, perhaps by using MIME.
Servers will probabaly construct a new document for each query, using
MIME's external reference feature where possible to avoid copying
large data files.
best wishes